Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9610/000046_owner-urn-ietf _Wed Oct 16 17:27:33 1996.msg

Internet Message Format | 1997-02-19 | 8KB

Received: (from daemon@localhost) by services.bunyip.com (8.6.10/8.6.9) id RAA21007 for urn-ietf-out; Wed, 16 Oct 1996 17:27:33 -0400
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1]) by services.bunyip.com (8.6.10/8.6.9) with SMTP id RAA21002 for <[e-mail]>; Wed, 16 Oct 1996 17:27:30 -0400
Received: from alpha.Xerox.COM by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA18288  (mail destined for [e-mail]); Wed, 16 Oct 96 17:27:24 -0400
Received: from golden.parc.xerox.com ([13.1.100.139]) by alpha.xerox.com with SMTP id <15662(2)>; Wed, 16 Oct 1996 14:23:50 PDT
Received: by golden.parc.xerox.com id <2764>; Wed, 16 Oct 1996 14:19:25 PDT
To: [e-mail]
Cc: [e-mail]
In-Reply-To: <[e-mail]> (message from Ron
    Daniel on Tue, 15 Oct 1996 09:48:22 PDT)
Subject: Re: [URN] a possible security architecture for URNs
From: Larry Masinter <[e-mail]>
Message-Id: <96Oct16.141925pdt."2764"@golden.parc.xerox.com>
Date: Wed, 16 Oct 1996 14:19:25 PDT
Sender: [e-mail]
Precedence: bulk
Reply-To: Larry Masinter <[e-mail]>
Errors-To: [e-mail]

>Thus spoke Larry Masinter (at least at 01:01 AM 10/15/96 PDT)
>>Check out
>>Rivest & Lampson, "A Simple Distributed Security Infrastructure"
>>    http://theory.lcs.mit.edu/~rivest/sdsi10.html

> Thanks for the citation. The paper is interesting. Unfortunately,
> we (the URN-WG) are not competent to judge the merits of this
> proposal relative to the SPKI work already going on in the IETF.

Ron, I think I might not have been clear about what part of that
document I thought you should check out. It isn't the particular
security mechanism that I was pointing to, but rather to the naming
method that was contained within the paper that had the important
property that it ALLOWED a security structure to be built that
accomodated it. What I found most compelling was how the authors had
thought through the issues of naming authority.

Let me excerpt the 'naming' part of the Rivest & Lampson paper, so
that it's clear that I'm talking about naming and not 'security' when
I say that this is an important paper to read:

> Egalitarian design-no global hierarchy necessary. Our proposal is
> egalitarian: each principal can make (signed) statements and requests on the
> same basis as any other principal. No hierarchical global infrastructure is
> required. Of course, in practice some principals would be more important
> than others, and SDSI allows for some principals to have special status as
> ``special roots,'' allowing SDSI to accomodate ``global names.'' But that is
> for convenience rather than necessity.

URNs are 'global names'. Any URN framework should clearly lay out how
the authority for naming gets delegated to sub-authorities in a way
that accomodates a wide variety of real world situations. The current
URN proposals lack the kind of flexibility that is contained in the
Rivest & Lampson document; that Rivest & Lampson have also laid out a
way in which authorization and name resolution can be distributed in a
trusted way is just an additional reason to pay attention to their
proposal.

> Local name spaces. Each principal can create his own local names with which
> he can refer to other principals. These local names arbitrarily chosen; they
> may be derived from nicknames, email addresses, account numbers, etc.:

>        jim
>        "Bob Jones, Jr."
>        account-314568901387
>        WebCo-Vice-President-John-Smith
>        [e-mail]
>        ( Accounting Bob-Smith )

>There is no fixed ``global'' name space giving a unique name for principals.
>The principal you call alice-smith may be different from the principal I
>call alice-smith. An exception is made for a small set of ``special root''
>principals, whom everyone calls by the same name.

Just as URLs needed "relative URLs", I think that this is an important
element of a global naming system. And the 'special root' principals
are indeed the top level of the URN hierarcies.

...

> Linked local name spaces. SDSI does not utilize a global name space, but
> rather provides means for conveniently linking local name spaces. Each
> principal can ``export'' his name/value bindings to others, by issuing
> name/value certificates. Thus, if my local name bob refers to some
> principal, then I can refer to the principal that bob calls alice as
>        ( ref: bob alice ) .
> We suggest that the user interface supply a bit of syntactic sugar to
> represent this as
>        bob's alice

...

> One can also have longer references, such as
>        bob's alice's mother ,

> which is the syntactically sugared version of
>        ( ref: bob alice mother ) .

> This reference is well-defined (for me) if I have bound bob to some
> principal, who in turn has bound alice to some second principal, who in turn
> has bound mother to some third principal. Other examples of extended
> references (with syntactic sugar) are:

>        Visa's account-314568901387
>        mit's lcs's rivest
>        cmu's eecs-dept's search-committee's chairman
>        GE's lighting-division's vp-of-marketing's secretary's assistant


...

With this background, we come to the part that I think represents a
viable URN framework for uniform universal names that can be
implemented in a distributed resolution framework with adequate
security:

> Accomodation for ``standard roots'' and global name spaces: We recognize
> that there are likely to be a set of standard ``special root'' principals
> that are ``universally'' recognized. These principals have SDSI reserved
> names ending with double exclamation marks (!!):

>        VeriSign!!
>        IAPR!!
>        USPS!!
>        DNS!!

> There will be very few of these special roots, and their names are bound to
> the same principal in every name space. This is arranged with suitable
> procedures (appropriate publicity, manual installation, cross-checking,
> etc.); we do not try to describe this in more detail. This gives SDSI access
> to ``standard'' name spaces:

>        VeriSign!!'s MicroSoft's Encarta-Division's Susan-Smith
>        DNS!!'s edu's mit's lcs's theory's Silvio-Micali
>        USPS!!'s USA's DOD's DCI
>        IAPR!!'s PCA-commerce's DEC's SRC's abadi
>        VeriSign!!'s Visa's account-234156742

> Each of these should be viewed as global names that evaluates to the same
> principal in every name space, since the first name (e.g. VeriSign!!) always
> evaluates to the same principal, and all of the subsequent names are
> relative.

> Although SDSI provides for special roots within a set of linked name spaces,
> this does not imply that each principal has a unique ``global name.'' A
> principal will have multiple global names if there are multiple paths from
> special roots to that principal. Thus,

>         VeriSign!!'s MicroSoft's CEO
>         DNS!!'s com's microsoft's "Bill Gates"

> may refer to the same principal. (Of course, one can check whether these two
> names evaluate to give the same public key, if one wishes.)

> DNS names have a special status. By special dispensation from its designers,
> SDSI includes custom treatment for DNS (Internet email) names, so that

>         [e-mail]

> is equivalent to:

>         DNS!!'s com's microsoft's penguin's Bob.Smith

> -that is, to:

>         ( ref: DNS!! com microsoft penguin Bob.Smith ) .

> How this works is described later on.

I hope this clarifies what I was asking people to "check out", namely:
a system of hierarchical naming where the issues of identity and
authority have been actually thought out.

I'll respond to other points in your message separately.

Larry